1. Field of the Invention
The present invention relates to a semiconductor integrated circuit device, and a debugging system and method for the semiconductor integrated circuit device. In particular, the invention relates to a semiconductor integrated circuit device including a microprocessor, and a debugging system and method for debugging the same.
2. Description of Related Art
In recent years, semiconductor integrated circuit devices (LSI) show a growing tendency to enhance the speed and performance of a built-in microprocessor. To that end, a semiconductor integrated circuit device of multiprocessor configuration which incorporates plural processors for attaining higher performance beyond the limit of the performance of a single microprocessor has been used.
FIG. 12 shows a configuration example of a general LSI of multiprocessor configuration. As shown in FIG. 12, the LSI 800 includes plural subsystems (subsystems 810a to 810c) and a memory 820. The subsystems 810a to 810c include CPU cores 811a to 811c and peripheral devices 813a to 813c such as DMA (Direct Memory Access) devices. The CPU cores 811a to 811c, the peripheral devices 813a to 813c and the memory 820 are commonly connected with a system bus 830. The system bus 830 is a high-speed bus for transferring data at high speeds with a system clock used as a reference.
The CPU cores 811a to 811cand the peripheral devices 813a to 813c share data in the memory 820 and independently execute processings in parallel to increase a processing speed. For example, the memory 820 stores programs executed in each subsystem, and the CPU cores 811a to 811c download the programs from the memory 820 to execute the programs or write data about the execution result to the memory 820. The peripheral devices 813a to 813c access the memory 820 in response to instructions of the CPU cores 811a to 811c or transfer data between the memory 820 and external units connected with the subsystems 810a to 810c. 
Meanwhile, in order to check the operations of an LSI of such multiprocessor configuration, debug is carried out. Examples of the debug includes software debug for executing a program prepared by a user and debugging the program, and hardware debug for executing an inspection program and eliminating malfunctions of a processor. In this specification, the debug includes the software debug and hardware debug.
FIG. 13 shows a configuration example of a conventional debugging system for debugging the LSI of multiprocessor configuration. The conventional debugging system includes an LSI 900 and a debug PC 990. The LSI 900 is connected with the debug PC 990 through a debug I/F (interface) 940.
The debug PC 990 includes a debugger 991 incorporating a debug control program, and the LSI 900 is debugged in response to user's manipulations of the debugger 991.
The LSI 900 is an LSI of multiprocessor configuration, and includes plural subsystems (subsystems 910a to 910c) and a memory 920. The subsystems 910a to 910c include CPU cores 911a to 911c, the DCUs (Debug Control Units) 912a to 912c, and peripheral devices 913a to 913c. 
Incidentally, FIG. 13 shows a connection form of bus lines used for debugging, and a connection form of bus lines under normal operations is omitted. That is, although not shown, the CPU cores 911a to 911c, the peripheral devices 913a to 913c and the memory 920 are commonly connected with a system bus similar to the illustrated example of FIG. 12.
As shown in FIG. 13, the LSI 900 is provided with a debugging synchronous bus 931 and a debugging external bus 932 as a bus used for debugging. The debugging synchronous bus 931 is commonly connected with the DCUs 912a to 912c. The debugging external bus 932 is commonly connected with the DCUs 912a to 912c and with the debug I/F 940. The debugging synchronous bus 931 is a high-speed bus like the system bus. The debugging external bus 932 is a low-speed bus that keeps pace with the debug I/F 940.
Such debugging systems enable debugging in plural debug modes. As an example of the debug modes, a “break mode” and an “on-the-fly trace mode” have been generally known. The break mode is such that if a predetermined break point (break condition) is reached during the execution of a program on a CPU, the execution of the program is stopped, and an internal state of the CPU is observed with the manipulations of the debugger. The on-the-fly trace mode is such that a predetermined break point (break condition) is reached during the execution of a program on a CPU, the execution of the program is suspended, and trace data at a predetermined trace point are collected, immediately after which the execution of the program is automatically restarted.
FIG. 14 shows an operation of a conventional debugging system (debugging method) in a break mode. For example, after a user selects the break mode with the debugger 991 of the debug PC 990, the following processing is carried out.
In the break mode, first, the debug PC 990 issues a request to set a break condition to a DCU selected by a user, for example, the DCU 912a through the debugging external bus 932 (S801). As a result, the DCU 912a sets a break condition in the CPU core 911a. 
Next, the debug PC 990 sends a request to execute a program to all DCUs, that is, the DCUs 912a to 912c through the debugging external bus 932 (S802). As a result, the DCUs 912a to 912c cause the CPU cores 911a to 911c to start executing a program.
Next, if detecting that the program execution satisfies the break condition, the DCU 912a causes the CPU core 911a to stop executing the program, and sends a notification to that effect to the remaining DCUs, that is, the DCUs 912b and 912c (S803). As a result, the DCUs 912b and 912c cause the CPU cores 911b and 911c to stop executing the program.
Next, the debug PC 990 downloads internal information of the CPU cores 911a to 911c designated by a user, from the DCUs 912a to DCU 912c through the debugging external bus 932 (S804). After the completion of confirming the internal information, the debug PC 990 issues a request to restart executing the program to all DCUs, that is, the DCUs 912a to 912c through the debugging external bus 932 (S805). As a result, the DCUs 912a to 912c cause the CPU cores 911a to 911c to restart executing the program.
FIG. 15 shows an operation of the conventional debugging system (debugging method) in the on-the-fly trace mode. For example, after a user selects the on-the-fly trace mode with the debugger 991 of the debug PC 990, the following processing is performed.
In the on-the-fly trace mode, first, the debug PC 990 issues a request to set a break condition to a DCU selected by a user, for example, the DCU 912a through the debugging external bus 932 (S901). As a result, the DCU 912a sets the break condition in the CPU core 911a. 
Next, the debug PC 990 issues a request to set a trace point to a desired DCU, for example, the DCUs 912a to 912c through the debugging external bus 932 (S902). As a result, the DCUs 912a to 912c set trace points in the CPU cores 911a to 911c. 
Next, the debug PC 990 issues a request to start executing a program to all DCUs, that is, the DCUs 912a to 912c through the debugging external bus 932 (S903). As a result, the DCUs 912a to 912c cause the CPU cores 911a to 911c to start executing a program.
Next, after detecting that the program execution satisfies the preset break condition, the DCU 912a causes the CPU core 911a to stop executing the program and sends a notification to that effect to the remaining DCUs, that is, the DCU 912b and DCU 912c through the debugging synchronous bus 931 (S904). As a result, the DCUs 912b and 912c cause the CPU cores 913b and 913c to stop executing the program. Then, the DCUs 912a to 912c collect trace data at the preset trace point from the CPU cores 911a to 911c and store the collected data in the DCUs 912a to 912c, and then cause the CPU cores 911a to 911c to restart executing the program (S905)
After that, each time the DCU 912a detects the break point, the operations of notification about the break detection to storage of trace data are repeated (S904′ and S905′). Then, the debug PC 990 collects the trace data stored in the DCUs 912a to 913c through the debugging external bus 932 (S906).
However, in the conventional debugging system, in the break mode, the execution of the program on each CPU core is stopped through the debugging synchronous bus, but the peripheral devices of each subsystem are not stopped. For example, when the peripheral device operates in parallel to the CPU core, if the peripheral device is operating even though the CPU core is stopped, an internal condition of the CPU core or a memory is updated, making it difficult to check the internal condition correctly. Further, if a break occurs, all CPU cores connected with the debugging synchronous bus are stopped all the time, and it is impossible to stop only a target CPU core.
Further, in the on-the-fly trace mode, the debugging synchronous bus is a high-speed bus, so the program execution on each CPU core may be immediately stopped to store trace data in the DCU. However, since the debugging external bus is a low-speed bus, it takes much time for the debug PC to collect trace data from the DCU. In general, a memory installed in the DCU for storing trace data is insufficient in memory capacity, and can store only one trace data, and the stored trace data is updated to new trace data soon. Therefore, it is difficult to collect target trace data.
Incidentally, as a conventional technique of debugging the LSI of multiprocessor configuration, a technique as disclosed in Japanese Unexamined Patent Publication Nos. 2004-342001 and 2003-15906 has been known.
As described above, in the conventional debugging system, when the break occurs, only the CPU core is stopped through the debugging synchronous bus, so the internal condition changes in some cases due to the peripheral devices in the subsystem. Further, when the break occurs, all CPU cores connected with the debugging synchronous bus are stopped. Thus, it is impossible to stop only a target CPU core. Further, the debugging synchronous bus commonly connected with the DCUs is a high-speed bus, but the debugging external bus is a low-speed bus that keeps pace with the external I/F. As a result, objective trace data cannot be collected in some cases.
Accordingly, the conventional debugging system has a problem in that debugging cannot be carried out correctly, an error is overlooked, and it takes much time to diagnose the cause of a problem, with the result that debug efficiency is low.